I am able to get the agent to work though it gets confused about its environment and responds with things like: "The files aren't found. Let me check if this is a macOS project and the files might be in a different location. The working directory is on Linux but the paths look like macOS. Let me check what's actually in the current directory." The agent is able to find the files mounted in the container with a little bit of effort though. But still the second message I send from Xcode causes a failure every time with that error: *** JSON-RPC global stream failed: The operation couldn’t be completed. (IDEIntelligenceProtocol.JSONRPCElement.Error error 1.)** I have not investigated the Hermes code myself but I did feed the error log to an LLM (so take this diagnosis for whatever it's worth: Quote below is from AI: **"Your log proves Xcode sent a cancel: 14:46:42 Cancelled session b05d... 14:46:43 Prompt on session b05d... 14:46:43 Turn ended: reason=interrupted_by_user The previous turn had completed at 14:41:35, more than five minutes earlier. ACP defines session/cancel as cancelling an ongoing prompt turn. Since no turn was running, Xcode’s cancellation appears stale, unnecessary, or part of its cleanup behavior. However, Hermes should safely tolerate that. Its current cancellation handler: Sets cancel_event. Calls agent.interrupt(). Does so even when state.is_running is false. The is_running check only controls whether Hermes saves current_prompt_text; it does not prevent the interrupt. When the next prompt begins, Hermes clears: state.cancel_event.clear() but does not clear the internal agent interrupt state. That explains why the second turn immediately reports: reason=interrupted_by_user and then throws: acp.exceptions.RequestError: Internal error Responsibility Xcode is the trigger: it sent a cancellation when Hermes apparently had no active prompt. Hermes is responsible for the failure: an idle or stale cancellation should not poison the next prompt or terminate the JSON-RPC request with an internal error. Xcode’s displayed error is only the consequence: its ACP peer returned an unhandled internal error, so Xcode reported the generic “JSON-RPC global stream failed.” I would report this primarily as a Hermes ACP bug, while explicitly noting that Xcode sends an idle session/cancel immediately before the next session/prompt. A robust fix is for Hermes to ignore cancellation when state.is_running is false and clear any stale internal interrupt state at the beginning of a new prompt. "** Figured I'd share. Would be cool to have a working local AI set up in Xcode. So close.

So I have my agent in a Docker container which makes set up with Xcode more difficult I think. Also hermes agent + Xcode fails every time on the second turn with: ** JSON-RPC global stream failed: The operation couldn’t be completed. (IDEIntelligenceProtocol.JSONRPCElement.Error error 1.) ** This may be a bug in Hermes and not Xcode. Not sure. But either way I think I'm throwing in the towel for now though. If anyone has pointers on getting Hermes (in Docker) + Xcode to work properly let me know. I don't want to move the agent out of the container.

Thanks for the recommendation! I just set this up as a custom ACP Agent in Xcode. Hoping to get better results now.

So switching to 'App Information' and adding the localization there worked. Now adding the localized app description and screenshots doesn't fail. That's the workaround I guess.

Can you also file a bug with your description for the team? Sure no problem. FB23519126

Yeah if NSApplication's -activateIgnoringOtherApps: method stops working this will be a problem for my app as well. I briefly replaced the to be deprecated method with -activate at some point (last year I think) but after discovering the same issue I had to revert back to -activateIgnoringOtherApps:YES

Interesting. I can't get in on macOS 27 yet. A bit too early for me and I have couple of things that need to get finished first. Hard for an indy dev to keep up! In one app I already have my own gesture recognizers I added for Force Touch trackpads years ago and it didn't interfere with the usual mouse stuff. I still override mouseDown: mouseDragged: -mouseUp: in all the 'big Appkit controls" (like NSCollectionView,NSOutlineView,NSBrowser). It's been awhile since I looked at that Force Touch gesture code so I wonder how this transition will affect that codebase. My biggest concern is Apple's most neglected control NSBrowser. Currently you have to use deprecated API to even get a dragging session to work. NSBrowser has some really old peculiar behaviors like posting live resize notifications for the window when only a column is being resized. And a lot of the browser stuff is done in the private table views which are still cell based. I think I put a hack gesture recognizer on the browser that helps me deal with some of its peculiar behaviors. I might have a swizzle or two, or three. I have so many hacks on NSBrowser I should probably get an Apple Design award for innovation. I would love to believe the changes they make to it (assuming they make changes to it) will make my life easier but I'm not very optimistic. I wonder why!

Also, Apple's own sample code for DragNDropOutlineView, which is linked to in the documentation for clickedRow, demonstrates using clickedRow in tableView(:shouldSelectRow:), which was the older version of tableView(:selectionIndexesForProposedSelection:). So if Apple's sample code uses it this way, I figure it should be fine. Great to know. Thanks for sharing that. Then it may be fine to read clickedRow in -tableView:selectionIndexesForProposedSelection: then. In my humble opinion Apple should add a note in the documentation like: The value of this property is meaningful in the target object’s implementation of the action, the double-action methods, and in the -tableView:selectionIndexesForProposedSelection:. delegate method Or maybe they just think it is so plainly obvious. I usually do my click specific stuff in the action method but given your unique requirements what you have might be the best way. I'm hesitant to offer any other possible solutions since I'm not on macOS 27 yet and things are changing. I'm definitely not looking forward to this gesture recognizer transition. I override -mouseDown: -mouseDragged: -mouseUp: etc. in like a million different places. Hope it goes easy and doesn't turn into two weeks of work just treading water.

Too bad nobody answered you. Six years later, I have a similar issue. I can't get NSPredicate +predicateFromMetadataQueryString: to work with InRange operator using dates either. In my case my app gets no results. But if I send the queryString to Finder via NSWorkspace +showSearchResultsForQueryString: Finder displays some results (though it appears inaccurate, as I know there are more files with a created date matching 'Today' than Finder is displaying). Instead of using InRange, this string works for me: kMDItemFSCreationDate >= $time.today && kMDItemFSCreationDate < $time.today(1) What's weird is if I send that string to Finder via NSWorkspace it does not work in Finder at all. So I guess the answer is to avoid using InRange with dates? There's not too much talk/examples for these old but still important APIs which enhance apps in meaningful ways!

I don't think you're supposed to read clickedRow in -tableView:selectionIndexesForProposedSelection:. Unless something has changed in macOS 27 the documentation for clickedRow states: The value of this property is meaningful in the target object’s implementation of the action and double-action methods. NSTableView is a subclass of NSControl. You should be able to pick up a click change by setting the table view's target-action instead of trying to do it in the delegate methods. Doing it in the delegate method like that might work but IMO this is cleaner and probably safer: -(void)windowDidLoad { [super windowDidLoad]; self.tableView.target = self; self.tableView.action = @selector(tableViewAction:); } -(void)tableViewAction:(NSTableView*)sender { NSLog(@"Clicked Column: %li Clicked row: %li", sender.clickedColumn, sender.clickedRow); } That will trigger on click. NSTableView does not invoke the action on keyboard navigation (at least not on macOS 26). I'm a bit worried that these AppKit changes might break a bunch of stuff. Hope not. I guess touch screen Macs are coming soon.

Thanks for responding. For some reason I didn’t get an email notification. I can’t use the editing string like that because the editing string is user controlled and isn’t guaranteed to be unique (the user can type the same editing string for different tokens which is valid for what I’m trying to do). So it looks like I’m going to have to write my own.

10 year later I filed a Feedback for this feature request 😂

If you change properties that implicitly cause the query to stop/restart on another queue (say from the main queue) the system logs out: NSMetadataQuery: has been started, but a modification to it was made from a different run loop or queue. Here's the backtrace: ( ... )

Hmm, I'll just wrap NSMetadataQuery behind my own class I think. I am assuming all properties need to be set on the operation queue, and I call start/stop on the operation queue as well.

So actually in System Settings I had the "Close windows when quitting an application" preference turned on, so the behavior I was witnessing in my testing is correct. It looks like Mail.app plays by its own rules because it decides to restore the windows anyway. It appears AppKit is doing the right thing here.